@tris203 will this break something for your plugin?

I am planning on waiting to merge this at least until nvim 0.11.1, so probably 1-2 months or something at least, but I think most of this refactor is finished

@tris203 will this break something for your plugin?

I am planning on waiting to merge this at least until nvim 0.11.1, so probably 1-2 months or something at least, but I think most of this refactor is finished

Yes, or at least our recommended configs.
NOTE: I will also have to look into the handlers, as we need to make sure we don't over ride your handlers you set

Rather than using vim.lsp.config directly, you can put the default config in the magic lsp/roslyn.lua location, then users can just overload that with their config.

I need to do the same with rzls.nvim and was thinking a similar time line, sometime in early summer ( I forgot different locations, early summer for me is sometime around June)

Rather than using vim.lsp.config directly, you can put the default config in the magic lsp/roslyn.lua location, then users can just overload that with their config.

Yeah I know. I might try it out to see if I like that better

I need to do the same with rzls.nvim and was thinking a similar time line, sometime in early summer ( I forgot different locations, early summer for me is sometime around June)

Yes that sounds good! We can coordinate on when we are merging these then

I have tried to make this as nice for the users as I can, since I am not hard deprecating the exe, args and config options, and also not the default install location of roslyn.

I have tried to still resolve those as previously, but just also issue a warning about it being deprecated, and point then in the correct direction to fix this.

It feels harsh to hard deprecate these things without any warning.

Would it be possible to integrate with neovim's lsp completion? Did a quick test but couldn't make it work.

  {
    "seblyng/roslyn.nvim",
    branch = "vim.lsp.config",
    ft = "cs",
    opts = {
      filewatching = "off", -- I'm on macOS and seems there's some watch-related issues
    },
  },

...

vim.lsp.config['roslyn'] = {
  cmd = {
    "dotnet",
    vim.fs.joinpath(vim.fn.stdpath("data"), "roslyn", "Microsoft.CodeAnalysis.LanguageServer.dll"),
    "--logLevel=Information",
    "--extensionLogDirectory=" .. vim.fs.dirname(vim.lsp.get_log_path()),
    "--stdio",
  },
  filetypes = { 'cs' },
}

...

vim.api.nvim_create_autocmd({ 'LspAttach' }, {
  callback = function(args)
    local client = assert(vim.lsp.get_client_by_id(args.data.client_id))
    if (client:supports_method('textDocument/completion')) then
      vim.lsp.completion.enable(true, client.id, args.buf, { autotrigger = true })
    end
  end,
})

vim.lsp.enable('roslyn')

Have to turn filewatching since I'm getting this message (nvim 0.11 through Neovide, macOS):

watch.watch: ENOENT: no such file or directory

Looking at lsp.log:

[START][2025-03-31 01:55:35] LSP logging initiated
[ERROR][2025-03-31 01:55:35] ...lsp/handlers.lua:562	"[Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.Razor.RazorDynamicFileInfoProvider] RazorDynamicFileInfoProvider not initialized. RazorWorkspaceService or RazorLspDynamicFileInfoProvider is null."
[ERROR][2025-03-31 01:55:35] ...m/lsp/client.lua:1043	"LSP[roslyn]"	"on_error"	{ code = "ON_INIT_CALLBACK_ERROR", err = "...es/.local/share/nvim/lazy/roslyn.nvim/lua/roslyn/lsp.lua:176: attempt to index field 'roslyn_root' (a nil value)" }
[ERROR][2025-03-31 01:55:35] ...lsp/handlers.lua:562	"[Microsoft.CodeAnalysis.LanguageServer.HostWorkspace.Razor.RazorDynamicFileInfoProvider] RazorDynamicFileInfoProvider not initialized. RazorWorkspaceService or RazorLspDynamicFileInfoProvider is null."

A couple of things:

• I think this is in a broken state right now, but I will fix that today
• Do not use vim.lsp.enable. That basically only sets up a FileType event. From looking at the source code, I don't think it is possible to use vim.lsp.enable here because vim.lsp.enable starts the server no matter what, but I need to be able to potentially not start it.
• When it is not in a broken state, it "works" with native completion, but it's not that good. I have reported that upstream: LSP: completion not filtering out unmatched entries neovim/neovim#32969

Can you test it now to see if you get any errors? I would hope that it should work with your above snippet if you just remove the enable call

No warnings, works on a dotnet new console project 👍

However I'm not getting good results on a more involved project (Unity project with many csprojs). The definitions within a file resolve fine (references to fields, or nested classes), but it's unable to find definitions outside of it. Not sure if filewatching has anything to do.

Is that any different from main branch? Are you using razor?

Is that any different from main branch?

No, same results. I had it working with 0.10 + cmp.

Wanted to check if 0.11 + lsp completion would work, but seems like it's not there yet.

Are you using razor?

No

Aaah you mean builtin completion isn't working with not finding definitions and such?

Yeah, I have also tried it a little bit out but to no luck. Hopefully the issue with filtering at least can be fixed, because without it it seems unusable

I've started getting this on a project I'm working on:

It started happening without doing config changes in-between, so I'm thinking there has to be a specific set of csproj settings that trigger it. I couldn't find what specificly.

Thought I'd share in case you know what's up.

Interesting... I am only on mobile now, but I see where it happens, but don't know why. It seems like type is an empty string or something, because it should concatenate something together with the error message you get.

Do you do anything special for this to happen? Could you try to explain when this happens? Like, do you just open a cs file and then this happens immediately?

It seems like, when reading the code, that this should happen when opening files under a specific directory, because it seems to happen when searching for the root solution.

Like, do you just open a cs file and then this happens immediately?

Yes exactly.

nvim: 0.11 (release)
roslyn: 5.0.0-1.25177.20+9ac5a7e4624bbb5328cc8eb044ada4b2235b0e34
config: as shown in #178 (comment)

I can help debug since I can repro always on this one project.

Could you try the latest changes, and produce the error, and then do :Roslyn log, and send med the contents? I cannot see why it would error, so some help would be really appreciated🙏

🤦 noticed the issue the moment I saw your log. I have a malformed solution named .sln, that was picked up. Renaming it to foo.sln, the issue no longer shows.

Ah okay, will try to have this in mind and see if I can improve the error message

Not sure where to ask this, I'll try here (is there a discord or other channels to chit chat usage / development?)

How do I cycle through overloads using the lsp? Is roslyn.nvim helping provide that? I was using lsp_signature but I'm wondering if there's a minimal no-plugin setup that I'm missing.

Not sure where to ask this, I'll try here (is there a discord or other channels to chit chat usage / development?)

Not for this plugin no

How do I cycle through overloads using the lsp? Is roslyn.nvim helping provide that? I was using lsp_signature but I'm wondering if there's a minimal no-plugin setup that I'm missing.

This should be in neovim core now with <C-s> keybind, but I haven't really gotten it to work, but was thinking that might be because of some hack I had for popups in another plugin. However, I have removed that now, but have not tested it after this. Anyways, I am not doing anything for this here, and this is for a signature plugin or in core

vim.lsp.buf.signature_help() (CTRL-S) shows "No signature help available", however, vim.lsp.buf.hover() (K) shows the signature (+ doc + number of overloads). Should roslyn.nvim be reporting signature information through signature_help?

No, that is up to the server

@seblyng maybe we could join forces and got a minimal config working in the official nvim-lspconfig repo, I created an draft PR with some changes I looked up from this repository:

neovim/nvim-lspconfig#3753

Yeah I would be open to that! I can add a review in nvim-lspconfig with some of my opinions

Now that roslyn_ls is supported in nvim-lspconfig, can we have a list of what this plugins offer more?

If i'm not mistaken, it:

• registers treesitter for c_sharp -> csharp
• has a picker when there are multiples .sln/.csproj & manual commands to select them
• handle decompiled requests

Yes I can try to summarize and add it to the readme. To add to what you are listing:

There is a bit more complex root dir detection with trying to find the project file of the file you are opening, and then trying to see if that is part of the solution it finds. It can also find solutions recursively in child directories

It is also implementing a couple of more handlers, but some of those at least might be accepted upstream if someone tries to send a PR there

registers treesitter for c_sharp -> csharp

This I have asked for to be added to nvim-treesitter previously and also now after nvim-lspconfig added support, but they didn't want to add it unfortunately

I think I want to merge this within max a couple of weeks so that I don't have to maintain two branches with potential new features/bug fixes. Do you have any reservations @tris203 ?

I think the current state is these breaking changes:

• Hard deprecation of exe, args and default installation options that has been soft deprecated for a couple of weeks now
• Soft deprecation of config option (will still work, but notify user about it being deprecated)
• Needs nvim 0.11

Works for me

rzls.nvim is >0.11 only already

Alright, since razor is already 0.11, I am just going to merge this now

registers treesitter for c_sharp -> csharp

This I have asked for to be added to nvim-treesitter previously and also now after nvim-lspconfig added support, but they didn't want to add it unfortunately

It looks like they discretely actually added it after they closed your issue, if I interpret it right?

https://github.com/nvim-treesitter/nvim-treesitter/blob/main/plugin/filetypes.lua

Yeah, I actually noticed that myself browsing through reddit this morning. I will remove the mention of the difference from the README, but I will keep the line that registers it a little longer, assuming that not necessarily everyone has migrated to the main branch of nvim-treesitter yet